Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #37761 - Allow rewrites needed for cockpit integration #1177

Closed
wants to merge 1 commit into from

Conversation

adamruzicka
Copy link
Contributor

No description provided.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, shouldn't this flag be with RewriteRule?

Like this:

<Location /webcon>
  ProxyPreserveHost On

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /webcon/(.*)           ws://127.0.0.1:19090/webcon/$1 [P,UnsafeAllow3F]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /webcon/(.*)           http://127.0.0.1:19090/webcon/$1 [P,UnsafeAllow3F]
</Location>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh, yes, sorry

@evgeni
Copy link
Member

evgeni commented Aug 22, 2024

Mhh, UnsafeAllow3F is disabling the fix for https://www.cve.org/CVERecord?id=CVE-2024-38474 which raises the following two concerns:

  • will this fail on systems that have no fix for that CVE yet? I guess so
  • disabling a fix seems like a suboptimal solution, can we avoid having question marks in the redirections?

@adamruzicka
Copy link
Contributor Author

adamruzicka commented Aug 22, 2024

will this fail on systems that have no fix for that CVE yet? I guess so

It will.

disabling a fix seems like a suboptimal solution, can we avoid having question marks in the redirections?

I'm afraid we cannot. I'll try looking into it a little bit more next week, but I'd be surprised if we could avoid it.

If I'm reading things right then the flow looks like this:

  1. User goes to /webcon/=${hostname}
  2. This hits foreman-cockpit
  3. foreman-cockpit redirects to ${foreman_fqdn}/cockpit/redirect
  4. ${foreman_fqdn}/cockpit/redirect redirects to ${foreman_fqdn}/webcon/=${hostname}?access_token=${token}
  5. This hits foreman-cockpit again, now that the token is available the rest of the flow can continue

@mvollmer Hi, since you originally wrote most of this, would you have any ideas how we could resolve this situation?

@adamruzicka
Copy link
Contributor Author

Ha! Scratch all that, apparently the token can be passed in as part of the query string or as an uri fragment, going with an uri fragment seems to do the trick

@adamruzicka
Copy link
Contributor Author

theforeman/foreman_remote_execution#918

@adamruzicka adamruzicka deleted the cockpit-3f branch August 22, 2024 13:57
@mvollmer
Copy link

Ha! Scratch all that, apparently the token can be passed in as part of the query string or as an uri fragment, going with an uri fragment seems to do the trick

Nice that you have figured this out!

I don't think I understand how this all works together in detail, but: is the rewrite rule only used during authentication, or also when Cockpit is already open and for loading the actual Cockpit URLs like .../cockpit/@localhost/system/index.html?

If so, this change to the rewrite rules might break downloading of SOS reports, and downloading of files in general in the new cockpit-files component. Downloading is done with "external channels" that use URLs like .../cockpit/channel/<token>?<base64-encoded-channel-options>.

If that is indeed the case, I think we can change Cockpit to not use the query part of URLs for this mechanism.

@adamruzicka
Copy link
Contributor Author

is the rewrite rule only used during authentication, or also when Cockpit is already open and for loading the actual Cockpit URLs like .../cockpit/@localhost/system/index.html?

As far as I can tell it is used for every single request, no matter what "stage" we're at.

If so, this change to the rewrite rules might break downloading of SOS reports

Sigh, looks like you're right, trying to download a sosreport does fail with a 403 and the unsafe rewrite error in httpd error log.

If that is indeed the case, I think we can change Cockpit to not use the query part of URLs for this mechanism.

That would be nice

Thinking out loud: right now, we rewrite anything coming to /webcon/... to 127.0.0.1:19090/webcon/.... Assuming we don't modify the path, could we proxypass the request instead?

@adamruzicka
Copy link
Contributor Author

Configuring httpd like this seems to work, any concerns about it?

<Location /webcon>
  ProxyPreserveHost On

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /webcon/(.*)           ws://127.0.0.1:19090/webcon/$1 [P]

  ProxyPass http://127.0.0.1:19090/webcon
</Location>

@evgeni
Copy link
Member

evgeni commented Aug 26, 2024

I thought [P] and ProxyPass are equivalent, but the are not! TIL

https://httpd.apache.org/docs/current/rewrite/flags.html#flag_p
https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass

But are we now proxying HTTP or WS?
The old code does it conditionally on HTTP:Upgrade, but now not anymore?

@adamruzicka
Copy link
Contributor Author

But are we now proxying HTTP or WS?

I would say we are still proxying both? http with proxypass and ws by rewriting the request and then proxying it?

The old code does it conditionally on HTTP:Upgrade, but now not anymore?

I'm not fluent in apache config, but isn't it more or less still there? Before we did if-elseif, now (in #1178) we do if-else, but it should be equivalent?

@mvollmer
Copy link

If that is indeed the case, I think we can change Cockpit to not use the query part of URLs for this mechanism.

That would be nice

Tell me if you need it! :-) I am not sure I can follow the discussion about the rewrite rules... The current assumption seems to be that ProxyPass works and can handle query parts just fine, and no changes to Cockpit are necessary, right?

@adamruzicka
Copy link
Contributor Author

The current assumption seems to be that ProxyPass works and can handle query parts just fine, and no changes to Cockpit are necessary, right?

Yup, so far we're good. I'll let you know if anything changes, thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants